Skip to content

V3 pre-merge; all the early bits, for V2#3028

Open
mgravell wants to merge 25 commits intomainfrom
marc/newcore-server
Open

V3 pre-merge; all the early bits, for V2#3028
mgravell wants to merge 25 commits intomainfrom
marc/newcore-server

Conversation

@mgravell
Copy link
Collaborator

@mgravell mgravell commented Mar 10, 2026 •
edited
Loading

This is a very large part of #3014, dragged down into v2 - pretty much as much as possible without making the v3 client changes

  • bring the eng build tools down, which has FastHash -> AsciiHash
  • bring RESPite down, in the current RespReader state from v3
  • bring the updated toy server down, entirely migrated to RESPite
  • make the minimal client changes to switch to AsciiHash an enum parsing instead of FastHash parsing
  • bring down the requests LCS changes and the missing RedisType.VectorSet
  • TFM cleanup
  • rev minor

Purposes of this PR:

  • minimize the size of the V3 PR
  • minimize the size of the V2 vs V3 delta going forward
  • bring the toy-server down to V2: the V3 core is a lot more stable for the server, and enables MULTI/EXEC (which cannot be easily implemented on the V2 core)

mgravell added 3 commits March 10, 2026 11:18
@mgravell
minimal pre-v3 consolidation:
8550511 
- add RESPite to the solution, but *DO NOT* reference from SE.Redis
- update eng tooling and migrate field parsing from FastHash to AsciiHash
- update the toy server *completely* to the v3 specification
@mgravell
- backport LCS and RedisType.VectorSet changes from v3
f08d0ed
@mgravell
CI
cba9bae
NickCraver
NickCraver reviewed Mar 10, 2026
View reviewed changes
Copy link
Collaborator

@NickCraver NickCraver left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left comments for 3.0 (holy bytes batman), but the more I look at this the more I think we should not backport a change this large with 2.x, and instead just get 3.x previews going. Let's discuss on call and see where y'all are at, just which way I'm leaning after assessing the diff.

@mgravell
Copy link
Collaborator Author

mgravell commented Mar 11, 2026 •
edited
Loading

@NickCraver I think I can summarize your feedback into a few buckets:

  • #if NET* - yep, simplified; let's do this!
  • a few hacky things around the analyzer project
    • tidy how referencing the analyzer works
    • do better about fromBytes
    • use the pre-built indented writer; I'm not sure about this one, seems very messy and low gain for the effort
  • a few questions over the key-events API: already considered and implemented as part of the existing shipped design; kicked to Busywork: build-tools; investigate / refactor to use IndentedTextWriter #3033
  • some confusion over what APIs we are adding: I suspect I confused you by refactoring the PublicAPI files, but short version: "we're not" - the only API additions are trivial and limited to the LCS/VectorSet ones Philo requested; everything else is just churn noise, so I don't think this is a concern
  • a doubt over the size of the FastHash -> AsciiHash migration

Is that fair? I think I've resolved everything except that last AsciiHash one; personally I'm more than comfortable with the FastHash -> AsciiHash, which is actually mostly renaming - I wanted it to be super clear that this has completely undefined behaviour outside of single-octet UTF8 code-points, hence the Ascii. The "big" part is the enum parsing logic, which is basically "take the old logic, and pre-generate a big-ass switch expression in the code-gen, rather than having the consumers write the switch in the consuming code", which makes the consuming code much easier to maintain (and get right); but the logic is unchanged.

@mgravell
Copy link
Collaborator Author

mgravell commented Mar 11, 2026 •
edited
Loading

Re "I think we should not backport a change this large with 2.x, and instead just get 3.x previews going." (@NickCraver); for context:

  • I need the this PR to get a stable and capable toy-server
  • I need a stable and capable toy-server to validate active:active (geo-redundancy) and "smart-client handoffs" (server notifications)
  • I need active:active and smart-client handoffs to land in v2, either directly or as backport

The simplest resolution is to land this first.

We can see this toy-server instability in the number of times I've tried to get #3030 green - the v3 server core is rock solid, vs:
image

@mgravell mgravell mentioned this pull request Mar 12, 2026
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@NickCraver NickCraver NickCraver left review comments

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@mgravell @NickCraver